Internet Warrior 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ Internet Warrior 1993 July / Internet Warrior No. 1 July 1993 - Austin Code Works.ISO / tools / oemacs / readme < prev

Wrap

Text File | 1993-04-14 | 21.1 KB | 468 lines

[ Here's yet another version of GNU Emacs that runs within Windows, but within a Windows DOS box. ] A preliminary version of "oemacs" has been made available via anonymous ftp. Oemacs is, basically, a version of GNU Emacs V18.59 that will work inside a Windows 3.1 DOS box (note that it is NOT a native Windows application, but works within a DOS box). It is partially based upon demacs, but is not compatible with it. At the end of this message, I've enclosed a copy of the file "readme.dos", which describes the features and problems of oemacs. READ THIS BEFORE OBTAINING OEMACS. ***** Why would you want to use "oemacs"? Because: * It works within a Windows DOS box. If you're feeling particularly masochistic, you can start more than one copy of oemacs, each in a different DOS box. * It works with plain MSDOS or Windows 3.1. * It fixes some bugs that demacs has. * It is based upon GNU Emacs V18.59. * It contains a few more useful emacs-lisp packages. One or two of the existing emacs-lisp packages have been upgraded, like info.el. * Pressing Ctrl-Break at *ANY* time will interrupt whatever Emacs is doing (assuming that it has not crashed and is not running "subprocesses"). With demacs, pressing Ctrl-Break just sends a C-c to demacs. ***** Why would you *NOT* want to use "oemacs"? Because: * It requires lots of RAM and lots of disk space. In order to run within Windows, you need at least 8MB of motherboard RAM, and I recommend that you have at least 12-16MB. You also need about 14MB of disk space to install oemacs, *NOT* including any space used to hold the .ZIP distribution files. Demacs requires much less resources. * It can take a while to start up (because it is not dumped, as is demacs). On my 33MHz 486DX, it takes about 10 seconds to start up. Demacs starts up much faster. * It doesn't handle large files very well. Demacs works much better for this. The biggest file that oemacs can handle is probably just under 16MB (although I haven't tried this -- the largest file that I've tried editing is 5MB). * It has a fixed internal stack size. Any highly recursive emacs-lisp functions *might* fail with this version. However, to minimize this problem, I've set the maximum stack size to 300KB. A typical Emacs running on my (real ;-) workstation uses up 100-150KB of stack, and so I gave oemacs a stack twice that size. The majority of people will probably never run into any stack problems, but you never know. Demacs doesn't have this problem. * Subprocesses don't work inside Windows. Then again, demacs doesn't work at all inside Windows. "Subprocesses" in MSDOS are also asynchronous; you CANNOT DO ANYTHING while a subprocess is running. * It is based upon GNU Emacs V18.59. (Yes, this is both a "feature" and a "problem".) A version by Pearl Software is based upon Lucid Emacs V19. ***** Where can you get a copy? NOTE: please access the following ftp site during "off-hours" -- sometime OTHER THAN 10AM-6PM EST (1500-2300 hours GMT/UTC). The site adminstrators have graciously provided the disk space, and I don't want to annoy them by overloading their site with ftp requests. NOTE THAT THIS IS A PRELIMINARY VERSION! BACKUP YOUR HARD DISK BEFORE USING OEMACS! Oemacs is available via anonymous ftp from theory.lcs.mit.edu, in /pub/emacs/oemacs: -rw-r--r-- 1 5536 toc 21120 Apr 2 13:27 README -rw-r--r-- 1 5536 toc 1077736 Apr 2 08:26 oemacs1.zip -rw-r--r-- 1 5536 toc 1089291 Apr 2 08:26 oemacs2.zip -rw-r--r-- 1 5536 toc 1094240 Apr 2 08:27 oemacs3.zip -rw-r--r-- 1 5536 toc 719295 Apr 2 08:27 oemacs4.zip All four files have been compressed using the new .zip 2.0 format (you can't use the old pkunzip programs), and must be extracted such that the subdirectory hierarchy is preserved (i.e., give the -d flag to pkunzip). Also, *ALL* four archives must be extracted in order to use this version of Emacs; while some files are unnecessary, they must be manually deleted (if you don't want them), after all of the files are extracted. Complete sources and binaries, with the exception of GNU termcap, are included. For a starting point, see the file "emacs-18.59/readme.1st". -- Darryl Okahata Internet: darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day. =============================================================================== OEMACS Release 1.0 Thu Apr 1 1993 While I would have liked to have used the name "demacs" or "demacs2", I didn't, because I don't want people thinking that this version is compatible with demacs. For reasons of ease-of-use and ease-of-installation, this version is partially incompatible with demacs. In particular, the two versions cannot share the same "_emacs" file (the "_emacs" file is the MSDOS equivalent of ".emacs"). The major differences between oemacs and demacs are: * Oemacs works within a Windows 3.1 DOS box. * Oemacs does not require a memory manager like EMM386 or QEMM, although it is recommended that one be used. * The _emacs files are different. In oemacs, the _emacs file has been simplified and streamlined. Demacs cannot use the oemacs' _emacs file, and oemacs cannot use the demacs' _emacs file. * The terminal config files ("lisp/term/ibmpc.el") are different. Oemacs doesn't rely on reprogramming the keyboard mapping via ANSI.SYS. Some versions of ANSI.SYS don't allow keyboard mapping, and some versions even crashed if this was attempted, and so oemacs uses a different method of keyboard handling. * Oemacs doesn't have the NEMACS or FEPCTRL code merged into the Emacs C code. I can't test these features, and so I didn't bother merging them in. The merge was done by hand (and not via patch(1)), and so merging these untestable features would have added more work, which I didn't want. The 8-bit support was kept, although it hasn't been tested much. * Oemacs needs to load the emacs-lisp files at startup. Demacs can be dumped, but oemacs cannot, and so oemacs needs to load the emacs-lisp at startup. * Oemacs is based upon Emacs V18.59. Demacs is based upon V18.55/V18.57. * The version of dired that comes with oemacs has been modified, and will work only with oemacs. This version of dired will not work with demacs. Here is a list of features and non-features in oemacs: * Oemacs works within a Windows 3.1 DOS box. * Enhanced C++ support has been added. Barry A. Warsaw's latest and greatest C++ mode has been added (including the "new syntax table" C code from Lucid V19 for better and quicker editing of C++/C comments). However, because DOS filenames cannot contain "+" characters, the filename has been renamed from "c++-mode.el" to "cpp-mode.el". * You can press Ctrl-Break at any time to interrupt oemacs. Note that the C-g key will only interrupt Emacs if Emacs is waiting for input. * Added Sam Kendall's (kendall@CenterLine.COM) etags++ tags program, which generates etags for C++ programs, as well as C, lisp, scheme, TeX, and Fortran programs. The DOS program name is "etags.exe". See the sources in "emacs-18.59/tags.xx" for details. * Better error message support. If there's an error in _emacs, you'll get something a bit more useful than "error in init file". * Fixed the bug where files on the command line had to contain names with forward slashes if they were not in the current directory. Filenames on the command line are now allowed to contain backslashes ("\") as directory separators. Users of MSDOS filename completion programs (like 4DOS) can use them to complete filenames for Emacs. The primary fix for this is in `expand-file-name'; this function will now lower-case the filename, and convert backslashes to forward slashes. * Fixed the bug where dired "randomly" displayed some file dates with a year (e.g., "1990") instead of a time (e.g., "14:53"). Now, dired will display the file's modification year if the file is *approximately* over six months old (the actual time is around six months plus or minus a day or two). This is more like Unix. * If Emacs runs out of memory, Emacs should get a "memory exhausted" error (however, I suspect that there are occasional corner cases where Emacs will crash). If Emacs does get a "memory exhausted" error, I strongly recommend that you exit and restart Emacs. Not only will this unfragment memory, but it will insure that Emacs' internal data structures are correct (which should be, but might not be, after a "memory exhausted" condition). * If Emacs is improperly installed and `(load "loadup.el")' cannot be done or encounters errors, Emacs will display an error message, abort, and return to the DOS prompt. Other versions of Emacs would simply start up an unusable (and nearly unquittable) Emacs. * I strongly recommend that you have 12-16MB of RAM on your motherboard, and that you have a permanent swap large enough to give you at least 16MB of free RAM after starting Windows 3.1. Merely starting Emacs within a Windows DOS box sucks up FOUR MEGABYTES of (virtual) RAM. I have no idea where the memory is going. I've written some code to do malloc(3) instrumentation, to see where the memory is going, but Emacs is only allocating 200-300KB of RAM at startup. I suspect that most of the RAM is being eaten by the DOS extender. (Interestingly enough, running this version under plain DOS uses much less memory.) Also note that Emacs allocates memory in sizes that are a power of 2. If, for example, you try to edit a 5MB file, Emacs will attempt to allocate an 8MB chunk of memory to hold the file. If you don't have that much memory left, Emacs will get a "memory exhausted" error. * `M-x compile' does not work within a Windows 3.1 DOS box, while it does work outside of Windows. If you try running Borland C++ 3.1 via M-x compile, the Borland compiler will hang. If you try running the WATCOM C/386 compiler via M-x compile, Emacs will abort (you will lose *ALL* your work) after the compile/link has completed. I suspect that this is a problem with the DOS extender (I can reproduce the problem with a small program that does nothing but execute system(2)), and so this problem will probably not get fixed. However, if you do `M-x compile' under plain MSDOS (which does seem to work), this version fixes the bugs in demacs 1.2.0 where the current drive is not saved. Your compile process can now switch drives and change directories, and the current drive/directory will still be saved. Also, as a special case, if the compile program is not on the current drive, the drive/current directory will be saved/restored on the drive where the compiled program is stored. * I've had this version lock up if I tried to execute a built-in DOS command (e.g., "rmdir") via `call-process' (the dired "delete directory" command will fail without locking up Emacs, though). * Running this version within a Windows 3.1 DOS box seems to cause Windows to disable the screen saver (if one is used). I have no idea what is happening here. * I left in the "int86" function. Be careful using this function, as you can easily crash the system by passing incorrect or bad values. * Because this version is compiled using WATCOM C/386 9.0, the maximum runtime stack size must be specified at link time (unlike demacs, whose stack grows as necessary). In this version, the stack size is fixed at 300K (if you want this changed, you'll have to relink emacs). * This version suffers from the NIH syndrome. While much of the code was stolen from demacs 1.2.0, much of it wasn't. I merged in, by hand (from diff -c), much of the MSDOS- and 8-bit-specific code, but left out the NEMACS and FEPCTRL (??) code. This will probably make a lot of people unhappy. However, I didn't want to introduce bugs by merging in code that I can't test, and so I didn't. * Undump/unexec does not, and probably will never, work. This means that you'll need mondo quantities of disk space to store ALL of the emacs-lisp files, and that starting Emacs will be SLOW. You will need perhaps 5-10MB for a minimal Emacs installation. On my 33MHz 486DX w/256KB cache, it takes about 10 seconds to start Emacs from DOS, and about 11 seconds to start from a Windows 3.1 DOS box. Not fast, but bearable. This problem is caused by the fact that the DOS extender (DOS/4GW) that comes with WATCOM C/386 has an sbrk() that somehow returns some pointer values LESS THAN the ending address of the BSS space. Can you say #define VIRT_ADDR_VARIES (for Emacs)? Another related problem is that the addresses returned by the DPMI provider in Windows 3.1 have some of the most significant bits set (e.g., 0x80000000 or 0x81000000). Can you say #define DATA_SEG_BITS with variable data segment bits (they vary between plain MSDOS and a Windows 3.1 DOS box)? Ptuii. This means that there's a potentially nasty situation that could occur if, in Windows, the DPMI provider starts returning pointers whose ~GCTYPEMASK bits vary; currently, Emacs will abort() if: (raw_pointer1 & ~GCTYPEMASK) != (raw_pointer2 & ~GCTYPEMASK) ("raw pointers" are pointers without the GC type bits.) Great possibilities for DATA LOSS exist here (if Emacs aborts), and I'm not sure if this "problem" will ever get solved. If this problem exists, it'll probably manifest itself as intermittent Emacs abort()'s (abortions?). However, I've tried editing 5MB files under Windows 3.1, and I haven't noticed any problems. I'd like to use djgcc, but I can't, until the djgcc DPMI issues are straightened out. * While I have pruned out much of the unnecessary, often platform-specific code and other files, I haven't cleaned out the emacs-18.59/etc and emacs-18.59/lisp directories; these directories contain unnecessary and often useless files (as far as MSDOS is concerned). * Unfortunately, this version does NOT work on Windows NT. At one time, I thought that it might, but it doesn't. * Instructions on compiling this version of Emacs has not been written. Everything that you need is here (except for the WATCOM C/386 C compiler, and the GNU termcap library). * Some new emacs-lisp files were added. Note that not all of the packages in the following list have been ported to MSDOS, if they need porting: + c++-mode.el (renamed to cxx-mode.el in this version) Barry A. Warsaw's C/C++ editing mode. + c-style.el This file allows you to configure sets of C code editing files. This is most useful if you have to edit C code in a number of different editing styles (e.g, different indentation, etc.). + header.el Add and maintain file headers. This mode knows about C comments (as well as shell script/perl comments), and will insert an appropriately-commented-out file header. When a file with a file header is saved, the modification time in the header is automatically updated just before the file is saved. + add-doc.el Appends user documentation to the end of the mode description. Normally, this would contain documentation about user enhancements/changes to the mode. + asm-mode.el A major mode for editing typical assembler code. + b-k-ring.el Browses the kill ring in another buffer. Use C-y to yank most recent kill ring entry (number 1.) into the buffer which was current when browse-kill-ring was invoked. Use a numeric argument (M-# C-y) to yank the corresponding entry. If you move point into the browse-kill-ring buffer, the keys C-y, y, Y, or SPC will yank the entry on the current line into the previous buffer. Note that browse-kill-ring should always be called before its contents is used; its buffer is not automatically updated when kills and yanks are done. This is normally not a problem, since yanks will cause the buffer to be deleted automatically. + blink-mt.el (was: blink-mtch.el) Yet another form of parenthesis-matching code. + c-com-ed.el (was: c-com-edit.el) c-comment-edit is a command that copies a C comment into a temporary buffer for editing under a more suitable major mode (usually text-mode). Once the comment is edited, c-comment-edit-end (normally bound to C-c ESC) replaces the old comment with the edited version, adding comment delimiters and leaders as necessary. c-comment-edit is ideal for large comments of these styles: /* /* /* ... * ... ** ... ... * ... ** ... */ */ */ + c-doc.el This package allows you to: 1) Enter a description of a function, with its name, a module, a file (normally taken to be the file the current buffer is visiting), a documentation string (as large as you'd like), the arguments (each with a name and a type and a documentation string), and a result type. 2) Edit the description (i.e., any name, doc string, containing module, etc.). 3) Get a buffer listing all functions/variables currently defined, all functions residing in a given module, etc. 4) Get a buffer showing all the information on a given function. 5) Read/write the documentation info from/to a file. 6) Visit a function's definition (basically a regexp on the function's name within the defining file). Kind of like a tags visit, but driven from its own info. 7) Insert an (ANSI-compatible?) external decl of the function. (Mostly works :-)). 8) Prompt for the arguments for a call to a given function, showing argument types/names for each one. 9) Complete the symbol in front of point from the function information. (Like M-Tab, but again using its own table.) 10) Read a function definition from C source, prompt for documentation, and add it to the list. + completi.el (was: completion.el) After you type a few characters, pressing the "complete" key inserts the rest of the word you are likely to type. This watches all the words that you type and remembers them. When typing a new word, pressing "complete" (meta-return) "completes" the word by inserting the most recently used word that begins with the same characters. If you press meta-return repeatedly, it cycles through all the words it knows about. If you like the completion then just continue typing, it is as if you entered the text by hand. If you want the inserted extra characters to go away, type control-w or delete. More options are described below. The guesses are made in the order of the most recently "used". Typing in a word and then typing a separator character (such as a space) "uses" the word. So does moving a cursor over the word. You automatically save the completions you use to a file between sessions. + edebug.tex + edebug.el Contains functions to allow the user to step through Emacs-lisp code (as a function is executed, the cursor moves over the source code). Breakpoints can be set. This is a much better Emacs-lisp debugger than the one that comes with GNU Emacs. + ereplace.el This source code replaces the emacs commands replace-string, replace-regexp, query-replace, and query-replace-regexp with a single command electric-replace-string. While entering from string, the user can use keystrokes to toggle between replacing regexps and strings, or between query and noquery modes. In addition, the user can choose to apply the replace over the entire (potentially narrowed) buffer, or over the entire region. Lastly, the user can yank the last string or regexp searched (depending on mode) to the from-string buffer. Quick summary: C-h Print this help message C-r Toggle between string/regexp replace M-q Toggle in and out of query replace mode C-l Toggle region mode (replace only in region) M-a Toggle full buffer mode C-s Yank the last string/regexp searched The key bindings are far from perfect. Perfect bindings should a) not interfere with useful standard editing functions (hence M-a and M-q instead of C-a, C-q). b) be reasonably mnemonic. + infer-mo.el (was: infer-mode.el) Functions to infer the proper mode of a file from its contents, not from its file extension. + info.el A new version of the info file reader. + log-msg.el Have you ever been frustrated by not being able to read an emacs message because it gets overwritten by another message? Then this package is for you. By setting the user variable "log-messages" to non-nil, you can have the messages logged for you in the buffer "*Message Log*" + macedit.el A keyboard macro editor. Very useful. From GNU Calc. + minibuf.el Functions to grow/shrink minibuffer window so that all lines show.